GuardDutyのRuntime Monitoringで「No Agent Reporting」が出てうまくEC2が接続できないときの対処法

こんにちは、臼田です。

みなさん、AWSの脅威検出してますか？(挨拶

今回はタイトル通りRuntime Monitoring機能を利用しているときに No Agent Reporting がでてコンピューティングリソースがうまくGuardDutyに接続できないときに行う対処について、実際にやったことをベースに紹介します。

概要

GuardDutyのRuntime MonitoringはECS/EKS/EC2の実行環境に対してエージェントを活用して、ファイルアクセス、プロセス実行、コマンドライン引数、ネットワーク接続などを監視して脅威を検出してくれます。詳細は下記を確認してください。

https://dev.classmethod.jp/articles/guardduty-ec2-runtime-monitoring-ga/

通常のGuardDutyの検出を行う際には、GuardDutyがマネージドにログを自動収集してくれますが、Runtime Monitoringは実行環境の中からログを収集するため、EC2等からVPC Endpointを経由してGuardDutyにログを収集します。

このVPC Endpointの作成や管理などは「自動エージェント設定」を設定しておくことでVPCに自動で行われます。だいたいこの機能に任せておけばうまくいくはずなんですが、うまくいかないときもありますよね。今回はそういうケースの対応です。

No Agent Reportingの対処

EC2を新規に起動してみて暫く待つと「ランタイムカバレッジ」でEC2の状態が表示されました。 Unhealthyです。

スクロールすると問題のところに No Agent Reporting とあります。クリックしてみると詳細リンクが表示されます。

フォワード先はAmazon EC2 インスタンスのカバレッジ - Amazon GuardDutyでした。いくつかのトラブルシューティングの手順が解説してありますのでこれを確認していくと良さそうです。

エージェントが動作しているかはAmazon EC2インスタンスのセキュリティエージェントの手動管理 - Amazon GuardDutyの下記コマンドで確認できます。

sudo systemctl status amazon-guardduty-agent

今回はエージェントが active で問題なかったため、ネットワークの問題だと考えました。ネットワーク周りはよくある質問 (FAQ) - Amazon GuardDutyに詳細が書いてあります。

いろいろ確認していくアプローチがありますが、今回はいい感じに可視化しつつ疎通の調査をしてくれるVPC Reachability Analyzerを使っていきます。画面を開いたら送信元に該当EC2インスタンス、送信先をVPC Entpointにします。

動かしてみたら「到達不可能」となりました。下に進みましょう。

VPC Entpoint側のeniが赤くなりここで止まっていることがわかります。リンクのSecurity Groupを開くとVPC Endpointに割り当てていたSecurity Groupで送信元を絞っていたことがわかりました。

今回私の環境では、完全に自動でセットアップできるようにする前に、手動でのセットアップを試していた都合上、通常はすべての通信を受け入れる設定になっているVPC EntpointのSecurity Groupが絞られていたことが原因でした。

というわけで直していきましょう。私の環境では、この絞ったSecurity Groupと対になるEC2用のSecurity Groupがあるのでこれを追加してあげます。

これで少し待つと、無事ステータスが Healthy に変わりました。脅威も検出できました。

まとめ

Runtime Monitoringでうまくいかなかった時の対処を紹介しました。ユーザーガイドへの誘導などがあり、確認していけば対処できましたね。

VPC Reachability Analyzerは非常に良い機能なのでバンバン使っていきましょう！